IN THE SPECIFICATION: 



At page 2, line 5, change the paragraph to read as 

follows: 

USSN 09/813,667 , [[(Docket 041-509-L) ] ] entitled "THIN 
CLIENT SIZING TOOL FOR ENTERPRISE SERVER FARM SOLUTION 
CONFIGURATOR" ; 
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ft ,. 

At page 2, line 8, change the paragraph to read as 

follows: 

USSN 09/813,671 , [[(Docket 041-510-L)]] entitled 
"CONFIGURATION INTERVIEW SESSION METHOD FOR THIN CLIENT SIZING 
TOOL"; 
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At page 2, line 11, change the paragraph to read as 

follows: 

USSN 09/813^672, [[(Docket 041-511-L) ] ] entitled 
"METAFARM SIZER CONFIGURATION OPTIMIZATION METHOD"; 
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At page 2, line 14, change the paragraph to read as 

follows: 

USSN 09/813/668 , [[(Docket 041-513-L) ] ] entitled 
"METHOD FOR CALCULATING USER WEIGHTS FOR THIN CLIENT SIZING 
TOOL"; 
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At page 2, line 27, change the paragraph to read as 

follows: 

USSN 09/813,669 , [[(Docket 041-514-L)]] entitled 
"METHOD FOR CALCULATING MEMORY REQUIREMENTS FOR THIN CLIENT 
SIZING TOOL"; 
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At page 2, line 20, change the paragraph to read as 

follows: 

[[USSN 09/443,926 (Docket 041-475-L) ] ] U.S. Patent 
6,496,948, entitled "METHOD FOR ESTIMATING THE AVAILABILITY OF AN 
OPERATING SERVER FARM"; 
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At page 2, line 24, change the paragraph to read as 

follows: 

[[USSN 09/474,706 (Docket 041-47 6 -LR) ] ] U.S. Patent 
6,571,283, entitled "METHOD FOR SERVER FARM CONFIGURATION 
OPTIMIZATION" ; 
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At page 4, line IB, change the paragraph to read as 

follows: 

A sequence of operations are involved using window 
screens as was indicated in the co-pending USSN 09/813,667/ 
[[(Docket 041-509-L) ] ] wherein a series of windows were provided 
into which information could be provided as input. 
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At page 6, line 12, change the paragraph to read as 

follows: 

Subsequently, the user-weights (whether light, medium, 
heavy or super heavy) , are calculated using as input information 
about the user types and the applications they use. This 
calculation is described further in the method described in co- 
pending USSN 09/813,668. [[, (Docket 041-513-L).]] 
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At page 6, line 28, change the paragraph to read as 

follows i 

After calculation of the memory requirements for the 
server, the server's solution is added to fill-out the Base 
Solutions report displayed in the Base Solutions Tab window, 
which then can be manipulated to calculate the default 

availability level as described in co-pending [ [USSN 

(Docket 041-475-L)]] U.S. Patent 6,496,948, entitled "METHOD FOR 
ESTIMATING THE AVAILABILITY OF AN OPERATING SERVER FARM" . Then 
this input is provided to fill out the inter-active Availability 
report and Availability Calculator that is displayed on the 
Availability Tab window of the configurator program 60. 
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At page 9, line 1, change the paragraph to read as 

follows z 

GLOSSARY LIST OF RELEVANT ITEMS: [[(GLOSSARY ADDED 

2/19/01)]] 
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At page 11, lines 24-25, change the paragraph to read 
as follows: 

10. AVAILABILITY LEVEL TAB WINDOW (FIG. 24 OF [[DOCKET 041-509- 
L):]] PSSN 09/813,667: This shows the Availability Calculator 
which helps to determine solutions that include future /growth 
potential requirements with a variety of redundancy levels. This 
screen is interactive and will take input for Adjusted Concurrent 
number of users, system repair times and redundancy levels. This 
screen is interactive and will take input for Adjusted Concurrent 
number of users, system repair times and redundancy levels and 
returns solution information such as estimated number of servers, 
# peak users, availability, estimated downtime, # redundant 
servers and server farm mean time to failure (MTTF) ♦ 
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At page 12, lines 22-23, change the paragraph to read 
as follows : 

13. BASE SOLUTIONS TAB WINDOW (FIG. 23 OF [[DOCKET 041-509-L) : ] ] 
USSN 09/813/667: Reports the minimum server configuration 
recommendation (i.e., not including additional redundancy or 
growth considerations) for each of the customer Site's server 
farms. A base solution includes the minimum number of servers and 
6B RAM required with regard to Operating system, # processors and 
MHz available for each server type supported by Unisys. 
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At page 14, lines 9-10, change the paragraph to read as 

follows: 

21. CUSTOMER DATA TAB WINDOW (FIG. 22 OF [[DOCKET 041- 509-L):]] 
USSN 09/813,667: Reports back to the customer the information 
that was collected during the interview session and that which the 
solution generation was based on. 
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At page 15, lines 3-4, change the paragraph to read as 

follows: 

24. DISK CAPACITY TAB WINDOW (FIG. 27 OF [ [DOCKET 041- 509-L):]] 
USSN 09/813/667; Reports on the disk capacity requirements 
determined by the interview session input and solution generation 
algorithms for each of the customer Site's Server Farms. 
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At page 15, lines 25 and 26, change the paragraph to 
read as follows: 

27. ESTIMATOR PROGRAM: This is a program which performs method 
steps for estimating system parameters such as the availability of 
an application program to run on any computer or server in the 
cluster of at least two servers or computers* This type of 
estimator program was the subject of a [ [co-pending application 
U.S. Serial No. 550,603]] commonly owned U.S. Patent 6,334,196, 
which is incorporated herein by reference. Another estimator 
program is the subject of this patent application. 
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At page 17, lines 7-8, change the paragraph to read as 

follows: 

36. NETWORK CAPACITY TAB WINDOW (FIG. 26 OF [ [DOCKET 041-509- 
L) : ] ] USSN 09/813/667: This is called Network Utilization now; 
reports on the estimated network activity measured in Kbps for 
each of the customer Site's Server Farms. 
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At page 18, lines 1-2, change the paragraph to read as 

follows: 

39. OPTIONAL SOFTWARE TAB WINDOW (FIG. 25 OF [[DOCKET 041-509- 
L) : ] ] USSN 09/813,667: Reports on the additional 
features/capabilities entered in the interview session regarding 
the customer's profile for each of the Site's Server Farms. 
Optional software requirements include such categories as Client 
Connection Methods, Enhancements, Environment support, Multimedia 
capabilities. Display characteristics, Protocol support, and 
Server Enhancements. 
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At page 20, line 10, change the paragraph to read as 

follows: 

49 • SIZING DATABASE: This is a collection of data on a computer 
output from the THIN CLIENT [[SEVER]] SERVER FARM AVAILABILITY 
CALCULATOR and used for storing the number of e-@ction Enterprise 
Server unit modules and their availability levels. 
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At page 23, line 8, change the paragraph to read as 

follows: 

DESCRIPTION OF PREFERRED EMBODIMENT: 

As is indicated in the overall system view for an 
Enterprise Server operation as shown in Fig. 2, a customer client 
profile 10 is developed from inputs indicating the customer's 
requirements, which is done by means of the configurator's 
interview session using a set of windows with inputs, as was 
illustrated in co-pending USSN 09/813,667. [[(Docket 041-509- 
L).]] 
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At page 23, lines 23-25, change the paragraph to read 
as follows: 

Fig. 3 is an example of a particular type of 
configuration known as a Server Met a farm 8. The Metafarm 8 may 
include a number of Server Farms designated as 10A, 10B, IOC . • 
• 10K. Each of the Server Farms will be seen to have a disk 
database server and a series of application programs with 
hardware servers. For example, Server Farm 10A will have a disk 
database server 12A, which is attached to a series of application 
programs [[10P, 20P, and PAN.]] 10P Al; 20P A2. Each of these 
programs is associated respectively with a particular hardware 
server Al, A2 and [ [N. ] ] NOP AN. 
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At page 23, line 30, change the paragraph to read as 

follows: 

Similarly, each one of the Server Farms, for example, 
such as the Server Farm 10K will also have a disk database server 
12K and a series of hardware servers Kl, K2, and KN, each of 
which has application programs designated as [[Kl, K2 and KN.]] 
10P Kl; 20P K2; KOP KN. 
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At page 25, lines 4-9, change the paragraph to read as 

follows: 

Before starting to generate a solution, a customer 
profile must have been gleaned via the configurator's interview 
process as indicated in co-pending USSN 09/813,671. [[(Docket 
041-510-L) . ] ] The resulting customer profile of the interview 
process act as input into the Solution Generation process and are 
stored in the Configuration Session DB 50 of Fig. 2, as also 
described in USSN 09/813,667. [[(Docket 041-509-L) . ] ] By showing 
an example of a relatively small customer, the Customer Profile 
might look like the following: 
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At tie bottom of page 27 and continuing to page 28, 
lines 3-4, change the paragraph to read as follows: 

It may be noted that the Application Installation Disk 
Requirements dimension will be filled-out in another part of the 
Sizing Tool algorithm. Then at step (D6a) it is noted that 
memory requirements are calculated for each user type using the 
application, here for Developers using Internet Explorer* This 
information is also stored in a mult i -dimensional array. This 
method is described in more detail in co-pending USSN 09/813, 669, 
[[(Docket 514-L]] which includes details on the algorithm to 
Calculate Memory Requirements) . 
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At page 28, lines 16-19, change the paragraph to read 
as follows: 

Step [[(D6a)]] D6A is then considered so that memory 
requirements are calculated for the user-type users using the 
application (Developers using IOCooker) as detailed in [ [Docket 
514-L.]] 09/813, 669. It is safe to say that no memory 
requirements are accumulated for 0 Developers. Then "Another 
Application?" is asked again at step (D7) and is answered "NO" 
after which the sequence dictates that the question "Another User 
Type?" is asked at step (D8) and answered "YES", which loops back 
to step (D4) . 
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At page 29, line 9, change the paragraph to read as 

follows: 

Then step [[(D6a)]] D6A calculates the memory 
requirements for Testers using Internet Explorer, And next the 
question "Another Application" at step (D7) is answered "YES" and 
the iOCooker Application is now considered with respect to 
Testers (D5) in Manufacturing Farm (i) . The total disk capacity 
is incremented for 300 Testers using IOCooker by adding 100 MB 
disk for the user working disk capacity requirements for each 
User type using the Application at step (D6), and is shown in 
Table IV. 
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At page 30, line 2, change the paragraph to read as 

follows: 

Again the memory requirements are calculated this time 
for Testers using iOCooker at step [[(D6a).]] D6A. At this 
point, ^Another Application?" (D7) is answered with "NO" and 
"Another User Type?" (D8) is also asked and answered with "NO". 
The flow sequence then continues so that the Application sizing 
information is retrieved at step (D9) from the Sizing Database, 
Fig. 2, item 30. The applications' disk installation 

requirements are added to the multi -dimensional array as seen in 
Table V. 
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At page 31, line 8, change the paragraph to read as 

follows: 

Basically/ user weighting considers the application 
input/output and processing attributes and the number of users as 
indicated in co-pending USSN 09/813,668, [[(Docket 041-513-L)]] 
which includes details on the algorithm to Calculate User 
Weights] • 
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At tie .bottom of page 33, and continuing to page 34, 
lines 1-2, change the paragraph to read as follows: 

The decision block question (D19) is then asked Is 

11 servers "Too Many Servers?", step (D19), to which the answer 
is "NO" in this example. "Too many servers" in a Server Farm is 
determined, for example, by engineering to be more than 160 
servers. This number is determined based on MTTF calculation 
overflow conditions and common sense with regard to ease of 
manageability. With the "NO" answer. Memory Requirements are 
calculated at step (D19N) as indicated in co-pending USSN 
09/813,669, [[(Docket 041-514-L) ] ] which gives details on the 
algorithm to Calculate Memory Requirements. 
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At the bottom of page 34, and continuing to page 35, 
line 12, change the paragraph to read as follows: 

Then, the next step is to calculate "default 
availability levels' 7 at step (D21) and fill-in the Availability 
report and Tab window which consists of an interactive 
Availability Calculator that is initially loaded with the four 
default availability level scenarios (D22) . The Availability 
calculator involves a table of server farm attributes that are 
manipulations of the base solution with regard to 3 variable 
factors; the number of adjusted concurrent users, the system 
repair time and the redundancy factor. For example, the base 
solution is reconfigured with 25%, 20%, 15%, and 10% redundancy. 
Estimated information about the number of servers, peak number of 
users, number of redundant servers Mean Time to Failure, 
estimated Availability and downtime are displayed with respect to 
the manipulated solution. The [ [co -pending USSN 09/443,926 
(Docket 041-475-L) ] ] commonly owned U.S. Patent 6,496,948 
illustrates the details on Calculating Availability. 
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At page 35, line 24, change the paragraph to read as 

follows: 

The Overflow flag, which indicates server overflow 
conditions, is re-initialized to FALSE at step (D24) to begin the 
iteration of the next loop regarding the next server model 
supported and the question "Another [[Server?*']] Server Farm" is 
posed at step (D25) . Here, the loop (D14) to (D26) is reiterated 
so that a base solution is generated for all supported server 
models with benchmark information stored in the Server Info 
Database (20, Fig. 2). 
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At page 36, line 13, change the paragraph to read as 

follows: 

Now, if the Server Farm Overflow list is NULL at 
[[stop]] step (D27), flow continues to (D28) but if the Server 
Farm Overflow list is not NULL at step (D27), the flow sequence 
continues to step (D27N) and a Warning Message is displayed 
indicating that there are one or more Server Farms in the Site 
which had base solutions that "exceeded" the maximum number of 
servers recommended for a Server Farm. Thus, in this case, the 
recommendation for action would be for the Customer-User to 
return to the configuration interview session and reconsider the 
number of Users which were assigned to the "overflowed" Server 
Farm so that the users are divided among more server farms and 
the maximum number of servers required per farm would no longer 
be exceeded. This alteration of the customer profile would cause 
the solution generation outcome to be free of overflow warnings. 
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At page 37, line 8, change the paragraph to read as 

follows: 

However, if the answer at step (D28) had been "YES", 

that is there are more Sites, then the Server Farm Overflow 

list is reset to NULL (D28Y) so that the last Site's Server Farm 
overflow list is not passed on to the next Site and the marker 
[[(Dx)]] "A, SEE FIG. 1A" sets the sequence back to step (Dl) . 
Another solution is then generated for the next Site which would 
be considered when stepping through the loop, steps (Dl) through 
(D28) . 
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At page 37, lines 17-22, change the paragraph to read 
as follows: 

Described herein has been a method for generating a 
configuration solution utilizing a Thin Client Sizing Tool in 
order to provide an optimum or desired configuration of, for 
example, a Server Farm or [ [Metaf arm, ] ] multiple Server Farms, 
for a particular customer. This solution is based on engineering 
provided benchmark test data for designated types of servers in 
order that the customer profile information about the number and 
types of users and the types of applications employed can be used 
as input to decide upon the appropriate number of servers and 
farms which can be configured together with the appropriate disk 
space and memory requirements, thus to satisfy the particular 
specifications and requirements of a given customer. 
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